So, as someone genuinely interested and not related to anyone in the discussion, can you give me an example of how this exploit could get used outside of parsing the results of a CSRF attack?

I have no intention of trying to attack your post, I just want to fully understand this and so far I haven't thought of a use for this that doesn't center around CSRF. I get that it allows cross-domain scripting in a way that browsers explicitly forbid, I just don't get how it could get used for anything other than parsing leaked data.

Thanks for the explanation.

As far as the definition issue, it seems that data leakage due to performing a request as a user as opposed to causing side effects due to performing a request as a user has a bit of a gray area in between. They both have the same root cause, unless I've missed something.

Also, cgisecurity defines the Gmail leakage of personal contacts as CSRF in the additional reading section ("Gmail Vulnerable to CSRF"), so it would seem that it also counts retrieval of data as an action.

I did notice that the wikipedia entry doesn't require all of the points listed in order for something to get labeled CSRF, just that they commonly have those characteristics. Since the cross-domain scripting hole in question meets three of these:

# Involve sites that rely on a user's identity
# Exploit the site's trust in that identity
# Trick the user's browser into sending HTTP requests to a target site)

These things led me (and others, apparently) to assume that that data leakage via this route constitutes a CSRF attack.

So, again, I just wanted to know if the cross-domain scripting attack could get used for anything else, since...well, honestly you know a hell of a lot more about web application security than I do and I want to make sure I fully understand this.

Well, the image example I would definitely not consider a CSRF. Basically, I would consider it one if somehow I could use your browser to retrieve the image for myself. Only when reading and recording the data (like with the Gmail contacts disclosure) would it become a CSRF to my understanding.

"But it is not the fact that I can force you to search, but the fact that I can read the result that is dangerous."

Completely, 100% with you.

"So do you consider it a CSRF vulnerability that I can load the Amazon.com frontpage in a hidden iframe of your browser, that will show your personal info (your name)."

Not at all, but if you can load the Amazon.com page and determine whether the user has logged in, or what they have in their cart, then I would.

"The moment I can use a browser vulnerability to read the content of the iframe or the moment the data comes back in JSON format that is vulnerable to <script> tags this becomes a vulnerability. But this has only partly to do with CSRF."

So if it only partly has to do with CSRF, what else does it have to do with as far as the web application itself goes? Forgive me if I seem to have missed something obvious, but as I said - I really do want to understand this if you see something that I don't, but so far I don't see anything other than information disclosure via a CSRF attack.

"And in the end lets not forget that even if you count it as CSRF, the damage can still be stopped by checking the Referer header."

Checking the Referer header would work for preventing the <script> vulnerability that sparked this discussion, definitely. However, it wouldn't stop someone from sniffing traffic and stealing the session in order to forge the request themselves, though that does rely on a vulnerability allowing session stealing in the first place. I do realize that moves the vulnerability further from CSRF, but the core defect of the web application remains the same.

Basically, I see the issue stemming from the failure to ensure that only the user, when directly using the application, has the ability to load the information and scripts into their browser. Anything relying on the honor system of browsers seems broken to me, since attackers can easily (or eventually) get around that.

So, essentially the fact that JSON evaluates as JavaScript by default forms the root of the problem?

I definitely see how Dr. Evil's pulling in publicly available information to his own browser doesn't have anything to do with CSRF, but I guess I just fail to see what part of this constitutes an attack at all. Just to recap: I do understand that this achieves its end result by way of altering the behavior of a script coming from another domain. Definitely not what browsers had intended, but seems like a side effect of the <script> tag supporting a src from another domain in the first place.

Does this mean that anyone embedding Google maps or some other JavaScript API in their site has basically just performed non-malicious cross-domain JavaScript hijacking? Or would they need to do something like this first:

function loopkup() { /* do something */ }
function Object() { this.a setter = lookup; this.a = 1; }

They use a script from some other site, just as your example of Dr. Evil fetching the JSON contacts. If they use a technique like this to display information to the user that the developers didn't intend to expose through the original API, does that mean that they've written malware?